This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
Data networks have become commonplace in today's world, allowing for various types of communications including e-mail, instant messaging, web browsing, voice, interactive and multimedia communications, etc. In the various types of data communications, it is important to maintain connections between an application server or service provider entity located on a data network and a communication device, such as a personal computer (PC) or a networked workstation as communications may occur at any time. This is in contrast more traditional telecommunications scenarios where an incoming call is detected on a dedicated line, connected, and released upon completion of the communication.
To maintain “always-on” connections, communication devices generally employ or have integrated therein, applications that send static or random data to application servers just to keep the connection open. Usually, this static or random data comprises a small static package sent every 30 seconds, for example. In a wired or “fixed power” environment, this transmission of random data is generally not a concern. However, in mobile environments the constant transmission of such data poses a major problem in that the battery life of a mobile device is constantly being depleted during each random data transmission. This promotes bad battery performance, as the mobile device has to maintain a constant or at least a periodic connection to a mobile station or application server. The problem is exacerbated when a single mobile device has multiple connections to multiple application servers, where connection maintenance is performed separately for each application server, because different applications may have different timing mechanisms for keep-alive messaging. Therefore, less battery life is available for actual communications in this situation. In conventional systems, always-on applications are implemented on mobile devices as a basic requirement for maintaining the constant connection between the mobile device and an application server in the network. In addition, there are generally several network components between the mobile device and the application server.
Low-level Internet Protocol (IP) connections are generally short-lived. A mobile service provider can control the timeout in the service provider's core network but typically cannot control the network timeouts in connections to application servers of 3rd party service providers. It should be further noted that connection timeouts in a mobile core network are not different for different communication protocols. In fixed network connections to application servers, there are significant timeout differences when utilizing Universal Datagram Protocol (UDP) and Transmission Control Protocol (TCP). UDP is a protocol that does not guarantee delivery and duplicate packet protection, while TCP provides a more reliable, connection-oriented protocol that generally operates in a layered protocol hierarchy. Mobile applications can use either UDP or TCP connections.
Different types of always-on IP applications are becoming an increasingly important part of not only mobile devices, but of communication terminals in general. An application cannot necessarily trust that a connection will remain open, as it may get closed by the network due to inactivity or some other network problem. Therefore, the connection must always be kept on. As discussed above, one example is e-mail. Quite often, obtaining an e-mail connection to corporate servers is not allowed without some kind of security. Security is offered via IPsec tunneling. In addition, connections generally involve traversing a Network Address Translation (NAT) device. The process of network address translation, also known as network masquerading or IP-masquerading, involves re-writing the source and/or destination addresses of IP packets as they pass through a router or firewall.
Most systems using NAT do so in order to enable multiple hosts on a private network to access the Internet using a single public IP address. For example, a local network may use IP addresses from one of the private IP address ranges (for example, 192.168.x.x and 10.x.x.x) and use a NAT router to connect to the Internet. As terminals send traffic from the local network, the NAT router translates the local IP address to one of its own public addresses. In order to get through NAT devices, an IPsec tunnel is created using UDP encapsulation. However, as NAT mappings used in UDP traffic are relative short (i.e., 20-60 seconds), a mobile device needs to send keep-alive message quite often to keep NAT mappings active. Otherwise, responses sent to the mobile device may not be able to be routed thereto.
This frequent keep-alive message sending has various drawbacks. First, a mobile device needs to wakeup, for example, every 20 seconds to send single keep-alive message. This changes the state of the radio bearer from IDLE to ACTIVE and the mobile device will stay in the ACTIVE state for several seconds before moving back to IDLE, just to be activated again due to the next keep-alive message. This frequent state change and usage of ACTIVE state causes significant battery consumption. In fact, the mobile device is in a type of high level standby mode where it is active almost continuously, resulting in high power consumption. Another problem is seen on network side. Because mobile devices are more frequently in an ACTIVE state, they will consume more network resources and a single base station is not able to serve as many mobile devices as it could if the mobile devices were not jumping between IDLE and ACTIVE due to keep-alive messages.
Previous solutions for this problem entail sending keep-alive messages from the mobile device itself to another mobile device or application server it wishes to remain connected to. Alternatively, an application server may send keep-alive messages to the mobile device. This method of keep-alive signaling has been specified for IPsec (RFC3948), incorporated by reference herein in its entirety, and MIP (RFC3519), incorporated by reference herein in its entirety. In addition, it is the responsibility of the terminal to send such a message if a NAT device is detected in the path. Other conventional systems involve a network entity such as a network operations center sending keep-alive messages to a gateway. However, this is again done for the purpose of the network operations center, and not on the behalf of another entity, such as a mobile device.